A user reports that their build file generation takes longer than 600 seconds.
It's probably a bug that we are so slow, but let's address that separately (maybe in our work for npm v7)

Also note we could have made this timeout user-configurable, but I think the extra API surface isn't worth the benefit.

Fixes bazel-contrib#2231

Tested by building //packages/angular:npm_package and don't get an extra .d.ts file in the package.
Also tested the negative case by making an invalid option and check that it's still reported.

Fixes bazel-contrib#2078

* docs: minor update for readibility and formating

Also recommend ts_project for new uses

Bazel is changing how @bazel_tools/conditions:darwin is implemented.
With old implementation based on flags, it was ok to have darwin and
darwin_x86_64 in a select. This was based on flag --cpu=darwin and
--cpu=dawin_x86_64.

New implementation is based on constraints, where "darwin" means OS (and
any CPU), while "darwin_x86_64" mean only specific CPU. As such they
cannot be used in the same select, because the selection would be
ambiguous.

Will revisit the linker and test, but this is blocking PRs from being merged

* feat(typescript): worker mode for ts_project

* chore: cleanup and declare protobufjs dependency

* fix: do not pass --watch for non-worker mode

* fix: do not test worker on windows

* fix: log on standalone failures

* chore: docs improvements

Co-authored-by: Alex Eagle <[email protected]>
Co-authored-by: Dan Muller <[email protected]>

… yarn

…contrib#2245)

Also allow non-ts files across src/bin dir, since they are not emitted we don't need the rootdir
calculation to take them into account. This lets the Angular compiler accept .ts sources from
source dir even if the css inputs are generated.

Current link returns 404, it seems that the url was somehow changed to .html from .md.

haha

…& fix link_workspace_root with no runfiles

It was using a non-standard repository, which had downtime this morning

Fixes bazel-contrib#1454

Example how this looks now:

```
[20 / 21] Bundling JavaScript bundle.js [parcel]; 4s remote-cache, darwin-sandbox
ERROR: /private/var/folders/r7/2kp53v7n091gcz93xlt7wtd80000gn/T/tmp-48948DHy4HrXTwhRy/BUILD.bazel:4:1: Bundling JavaScript bundle.js [parcel] failed (Exit 1) parcel.sh failed: error executing command bazel-out/host/bin/external/npm/parcel-bundler/bin/parcel.sh build foo.js --out-dir bazel-out/darwin-fastbuild/bin --out-file bundle.js ... (remaining 2 argument(s) skipped)

Use --sandbox_debug to see verbose messages from the sandbox
ERROR: rules_nodejs linker requires Node v10 or greater, but is running on 8.11.2
Note that earlier Node versions are no longer in long-term-support, see
https://nodejs.org/en/about/releases/
INFO: Elapsed time: 40.360s, Critical Path: 12.97s
INFO: 0 processes.
FAILED: Build did NOT complete successfully
//:test                                                               NO STATUS
```

Fixes bazel-contrib#2304

Fixes bazel-contrib#2298

chore: allow node versions >=12 <=14

… to npm_package_bin driven actions (bazel-contrib#2353)

NPM tools are currently run out of external/{md}/node_modules. If the
tool loads user-provided files in the execroot, which is the common
case, then this can lead to bad interactions.

Two examples of bad interactions are:
  1. A tool that loads React and the user code too,
     hooks becoming unusable.
  2. A tool that calls into a bundler like Webpack,
     potentially bundling duplicate packages.

Signed-off-by: Duarte Nunes <[email protected]>

…mples

See bazelbuild/bazel#8622
This is an expected breaking change in Bazel 4.0